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Abstract — This  paper  provides  an  update  to  [1]  on  the 
developments  associated  with  a  Prognostics  and  Health 
Management  (PHM)  system  design  tool  that  integrates  a 
model-based  FMECA  methodology  with  state-of-the-art 
system  simulation  directly  linked  to  downstream  Life  Cycle 
Costs  (LCC).  This  design  tool  will  seek  out  recommended 
PHM  system  designs  based  on  a  cost  function  that 
accurately  represents  key  LCC  variables  such  as  system 
availability,  maintainability,  reliability,  and  failure  mode 
observability.  The  tool  will  be  capable  of  assessing  PHM 
sensor  requirement  specifications  at  the  component  and 
subsystem  levels,  and  will  then  allow  for  integration  into  a 
broader  integrated  system  model.  Tradeoff,  sensitivity  and 
“what  if’  analysis  will  then  allow  the  designer/user  to 
examine  the  cost/benefit  relationship  of  either  adding  or 
removing  sensor  and  algorithms  under  consideration  for  the 
PHM  design.  An  interactive  database  cf  existing  PHM 
technologies  for  specific  applications  will  also  be  accessible 
within  the  design  tool  for  suggesting  sensors/algorithms  for 
monitoring  various  system  parameters.  Finally,  the 

approach  introduces  a  collaborative,  web-enabled 
environment  for  enhanced  realization  and  virtual  simulation 
of  PHM  system  design.  A  simplified  example  of  a  Health 
Management  system  cost/benefit  analysis  on  an  aircraft 
electromechanical  valve  is  provided  for  illustration  of  the 
concepts  introduced. 


1.  Introduction 

The  application  of  “health”  or  “condition”  monitoring 
systems  serves  to  increase  the  overall  reliability  of  a  system 
through  judicious  application  of  intelligent  monitoring 
technologies.  A  consistent  health  management  philosophy 
integrates  the  results  from  the  health  monitoring  system  for 
the  purposes  of  optimizing  operations  and  maintenance 
practices  through,  1)  prediction,  with  confidence  bounds,  of 
the  Remaining  Useful  Life  (RUL)  of  critical  components, 
and  2)  isolating  the  root  cause  of  failures  after  the  failure 
effects  have  been  observed.  If  RUL  predictions  can  be 
made,  the  allocation  of  replacement  parts  or  refurbishment 
actions  can  be  scheduled  in  an  optimum  fashion  to  reduce 
the  overall  operational  and  maintenance  logistic  footprints. 
Fault  isolation  is  a  critical  component  to  maximizing  system 
availability  and  minimizing  downtime  through  more 
efficient  troubleshooting  efforts. 

Aside  from  general  exceedence  warnings/alarms,  health 
monitoring  initiatives  mostly  take  place  after  in-field 
failures  (and  substantial  costs)  have  been  incurred.  To 
address  this  issue,  this  paper  proposes  the  concept  of  a 
Health  Management  Virtual  Test  Bench  or  a  software  tool 
that  is  not  only  used  for  health  monitoring  system  design  but 
also  for  system  validation,  managing  inevitable  changes 
from  in-field  experiences,  and  evaluating  system  design 
tradeoffs  (Figure  1) . 
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Figure  1  -  Health  Management  with  System  Design 

Because  an  initial  system  FMECA  is  performed  during  the 
design  stage,  it  is  a  perfect  link  between  the  critical  overall 
system  failure  modes  and  the  health  management  system 
designed  to  help  mitigate  those  failure  modes.  Hence,  a  key 
aspect  of  the  process  presented  links  this  traditional 
FMECA  analysis  with  health  management  system  design 
optimization  based  on  failure  mode  coverage  and  life  cycle 
cost  analysis. 

2.  Role  of  FMECA  in  Health  Management 

FMECA’ s  historically  contain  3  main  pieces  of  information 
as  described  below: 

1.  A  list  of  failure  modes  for  a  particular  component 

2.  The  effects  of  each  failure  mode  ranging  from  a  local 
level  to  the  end  effect 

3.  The  criticality  of  the  Failure  mode  (I  -  IV),  where  (I)  is 
the  most  critical 

While  this  type  of  failure  mode  analysis  is  beneficial  in 
getting  an  initial  (though  generally  unsubstantiated)  measure 
of  system  reliability  and  identifying  candidates  for 
redundancy,  there  are  several  areas  where  fundamental 
improvements  can  be  made  so  that  FMECA’ s  can  assist  in 
health  monitoring  design.  Four  shortcomings  of  traditional 
FMECA’ s  are: 

1.  Traditional  FMECA  does  not  address  the  precursors  or 
symptoms  to  failure  modes. 

2.  To  move  maintenance  from  reactive  to  proactive,  it  is 
important  to  focus  on  both  system  and  component  level 
indications  that  the  likelihood  of  a  substantial  failure 
mode  has  increased.  Failure  mode  symptoms  that  occur 
prior  to  failure  are  these  indications.  An  example  of 
failure  mode  symptoms  associated  with  a  bearing 
would  be  an  increase  in  spike  energy  or  an  increase  in 
the  oil  particulate  count. 

3.  Traditional  FMECA  does  not  address  the  sensors  and 
sensor  placement  requirements  to  observe  failure  mode 
symptoms  or  effects. 


4.  Traditional  FMECA  does  not  address  health 
management  technologies  for  diagnosing  and 
prognosing  faults. 

5.  Traditional  FMECA  typically  focuses  on  subsystems 
independently. 

With  these  shortcomings  in  mind,  a  new  approach  has  been 
developed  that  extends  far  beyond  traditional  FMECA 
capability  and  used  in  the  design  of  health  monitoring  and 
management  systems. 


3 .  Approach  to  Health  Management 
Design 

Figure  2  provides  an  overview  of  the  approach  to  health 
management  system  design  optimization.  A  basic 
description  of  each  block  will  be  given  first,  then  details 
associated  with  each  block  will  follow.  First,  a  Function 
Block  diagram  of  the  system  must  be  created  that  models 
the  energy  flow  relationships  among  components.  This 
functional  block  diagram  provides  a  clear  visbn  of  how 
components  interact  with  each  other  across  subsystems.  On 
a  parallel  path,  a  tabular  FMECA  is  created  that  corresponds 
to  a  traditional  FMECA  except  it  contains  failure  mode 
symptoms,  as  well  as  sensors  and  diagnostic/prognostic 
technologies.  Alternately,  a  system  response  model  may  be 
used  for  assessing  sensor  placements  and  observability  of 
simulated  failure  modes  thus  offsetting  the  manual  burden 
of  creating  the  FMECA.  Finally,  maintenance  tasks  that 
address  failure  modes  are  included. 

The  information  from  the  Functional  Block  diagram  and  the 
tabular  FMECA  is  automatically  combined  to  create  a 
graphical  health  management  environment  that  contains  all 
of  the  failure  mode  attributes  as  well  as  health  management 
technologies.  The  graphical  health  management 
environment  simply  a  sophisticated  interface  to  a  relational 
database.  Once  the  graphical  health  management  system 
has  been  developed,  attributes  are  assigned  to  the  failure 
modes,  connections,  sensors  and  diagnostic/prognostic 
technologies.  The  attributes  are  information  like  historical 
failure  rates  (failures  /  1E5  operating  hours),  replacement 
hardware  costs,  false  alarm  rates  etc.,  which  are  used  to 
generate  a  fitness  function  for  assessing  the  benefits  of  the 
health  management  system  configuration.  The  “fitness” 
function  criteria  include  system  availability,  reliability,  and 
cost.  Some  of  these  attributes  must  be  manually 
determined,  if  known,  while  others  are  related  to  the 
attributes  of  the  diagnostic/prognostic  technologies  can  be 
determined  from  independent  measures  of  performance  and 
effectiveness  tests  or  from  pre -developed  databases. 
Finally,  the  health  management  configuration  is 
automatically  optimized  from  a  cost/benefit  standpoint 
using  a  genetic  algorithm  approach.  The  net  result  is  a 
configuration  that  maintains  the  highest  system  reliability  to 
cost/benefit  ratio. 
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Figure  2  -  Architecture  of  PHM  Design  tool 


Figure  3  -  Functional  Block  Diagram  Layout 


4.  Functional  Block  Diagram 

The  Function  Block  Diagram  (FBD)  contains  an  integrated 
representation  of  how  components,  subsystems  and  systems 
interact  with  one  another.  It  is  not  a  simulation,  only  a 
hierarchical  map  of  physical  energy  flows  (i.e.  torque 
transfer,  current,  pressure).  This  energy  flow  map  serves  as 
the  backbone  for  the  health  management  design 
environment  because  it  contains  the  failure  mode  symptoms 
and  effects  as  well  as  capturing  their  temporal  paths.  Figure 
3  shows  an  example  of  a  functional  flow  diagram  at  a 
“system”  level.  One  could  select  any  of  the  components  to 
reveal  specific  interactions  between  its  associated  subsystem 
components. 


5.  Enhanced  FMEC A 

As  previously  mentioned,  with  this  approach,  traditional 
FMECA  analyses  were  enhanced  with  the  addition  of 
sensors,  health  monitoring  technologies  and  failure 
symptoms.  Figure  4  shows  an  example  of  an  enhanced 
FMECA  performed  on  a  portion  of  a  fuel  system  for  a  F 
100  engine  created  by  Penn  State  ARL  and  Impact 
Technologies. 

As  with  traditional  a  FMECA,  the  failure  mode  is  provided 
along  with  its  effects  (ranked  from  top  to  bottom  as  primary, 
secondary,  tertiary,  etc.).  The  Criticality  or  Frequency  of 
Occurrence  of  the  failure  mode  is  ranked  from  A  to  E 
where: 


A  =  Frequent, 

B  =  Probable, 

C  =  Occasional, 
D  =  Remote, 

E  =  Improbable 
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Figure  4  -  Tabular  FMECA  of  a  F  - 100  Fuel  System 


In  practice,  this  Criticality  letter  would  be  associated  with  a 
specific  probability  of  failure  range. 

The  Severity  of  the  failure  mode  is  ranked  from  I- IV  where: 

I  -  Catastrophic, 

II  -  Critical, 

III  -  Marginal, 

IV  -  Negligible 

The  first  FMECA  enhancement  is  that  failure  mode 
symptoms  have  been  added  to  the  “effects”  column  and  are 
shaded  in  blue  (or  light  gray).  Failure  mode  symptoms  are 
events  that  can  be  observed  prior  to  the  failure  mode 
occurring  or  when  the  failure  mode  is  in  a  very  early  stage 
of  development.  Subsequent  effects  may  or  nay  not  be 
downstream  failure  modes.  In  the  case  where  an  effect  is  a 
downstream  failure  mode,  the  failure  mode  of  focus  could 
be  considered  a  failure  mode  precursor. 

The  “Component”  column  identifies  the  component 
immediately  affected  by  the  failure  mode  while  “Module”  is 
the  subsystem  in  which  the  component  resides.  This 
functional  relationship  is  cross-referenced  with  the 
functional  block  diagram.  In  a  similar  fashion,  the  “Sensor” 
column  lists  the  sensor  that  can  observe  the  symptom  or 
effect  while  “S_Module”  is  the  subsystem  in  which  the 
sensor  resides  and  “S_Component”  is  the  component  it  is 
linked  to.  All  sensors  in  this  example  are  required  for 
control  or  safety  purposes.  Finally,  “Diagnostics”  and 
“Prognostic”  column  have  been  added.  The  “Diagnostics” 
column  describes  if  there  are  any  discrete  diagnostic  (Built 
in  Test  (BIT))  or  continuous  processing  algorithms  that  can 
observe  the  symptom  or  effect.  The  “Prognostics”  column 
describes  any  prognostic  algorithms  that  can  be  used  to 
obtain  a  RUL  prediction  on  the  failure  mode. 


6.  Response  Models 

In  some  cases,  a  model  of  a  subsystem  may  be  developed 
that  can  provide  valuable  insight  into  where  sensor  are 
likely  to  have  the  most  observational  quality  on  failure 
modes.  This  optional  level  of  fidelity  allows  for  detailed, 
physics -based  subsystem  modeling,  to  be  used  for 
examining  PHM  trade-offs.  Such  tradeoffs  at  this  level 
would  include  analyzing  the  number  of  sensors  required, 
location  of  the  sensors  and  associated  algorithms.  This 
type  of  mo  del  would  be  integrated  in  the  overall  HM  design 
environment  thus  far  discussed  where  cross-system 
influences  can  be  examined  and  accounted  for  (Figure  5). 
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Figure  5  -  Response  model  integration  in  the  overall  HM 
model 


One  such  system  response  model  for  a  hydraulic  system 
developed  by  Dr.  Jacek  Stecki  et  al.  of  Monash  University  is 
shown  in  Figure  6.  This  model  illustrates  how  the  system 
model  may  be  perturbed  to  simulate  how  the  effects  of 
certain  modes  propagate  in  time  and  space.  Sensor  / 
algorithm  combinations  can  be  examined  for  their  ability  to 
detect  the  perturbations. 


Figure  6  -  Example  of  a  detailed  system  response  model 


7 .  Health  Management  Attributes 

To  autonomously  evaluate  the  cost/benefit  of  a  HM  system 
configuration,  all  aspects  of  the  system  must  ultimately  be 
assigned,  or  modify,  a  dollar  value  so  that  a  cost  function 
can  be  generated  and  optimized.  Some  of  these  “attributes” 
are  more  easily  derived  that  others.  The  attributes  assigned 
within  a  HM  system  and  their  respective  icons  are  linked  to 
Failure  modes  (F/FM),  Sensors  (eye),  Effects,  Diagnostics 
(Stoplight-discrete,  x-y  plot  -  continuous),  Prognostics 
(stethoscope)  and  Maintenance  Tasks  (M).  A  short  list  of 
these  attributes  is  shown  in  Figure  7.  Some  of  the  less 
obvious  attributes  are  described  next. 
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detection  quality  of  the  technology.  A  physical  prognostic 
model  (i.e.  based  on  an  FE  model)  would  ideally  have  a 
higher  prognostic  accuracy  than  an  experienced-based 
model  (i.e.  Weibull  distributions  of  historical  failure  rates). 
More  details  on  model  fidelity  are  discussed  in  [2]. 

A  valid  concern  is  how  the  technical  attributes  of  diagnostic 
and  prognostics  technologies  can  be  determined.  One 
method  is  addressed  in  [1],  whereby  algorithms  are  test 
objectively  from  performance  and  effectiveness  standpoints 
using  transitional  run  to  failure  data.  Of  course  in  the 
absence  of  this  type  of  information,  and  with  a  new 
sensor/algorithm  combination,  an  educated  guess  may  be 
the  only  option. 


Figure  7  -  Short  list  of  HM  attributes 
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8.  Cost  Function 


Sensors  are  defined  in  the  model  as  components  for 
measuring  physical  quantities  such  as  temperatures, 
pressures  and  currents.  The  “Observational  Quality” 
attribute  of  a  particular  sensor  is  a  measure  of  the  sensitivity 
with  which  it  is  able  to  pick  up  a  physical  signal  linked  to  a 
particular  failure  mode.  For  example,  an  accelerometer  stud 
mounted  on  top  of  a  bearing  casing  may  have  a  better 
observational  quality  than  one  magnetically  mounted  some 
distance  away. 

Diagnostic  and  Prognostic  Attributes 

Diagnostics  can  be  either  discrete  or  continuous.  Discrete 
diagnostics  are  traditionally  algorithms  that  produce  0  or  1 
depending  on  if  a  threshold  has  been  exceeded.  Many  types 
of  Built  In  Tests  (BITs)  can  be  classified  as  Discrete 
Diagnostics.  An  example  of  a  discrete  diagnostics  is  an 
Exhaust  Gas  Temperature  (EGT)  reading  that  has  exceeded 
a  predetermined  level. 

Continuous  diagnostics  are  algorithms  designed  to  observe 
transitional  effects  and  diagnose  a  failure  mode  based  on  the 
method  and  rate  in  which  the  effect  is  changing. 
Continuous  diagnostics  are  usually  associated  with 
observing  the  severity  of  failure  mode  symptoms.  Examples 
of  continuous  diagnostics  would  be  a  spike  energy  monitor 
for  identifying  low  levels  of  bearing  race  spalling  or  an  A. I. 
classifier  for  diagnosing  that  a  valve  is  sticking.  The 
“Detection  Confidence  score  (0-1)  -  (DDC)”,  and  “%  false 
positive  score  (0-1)  -  (DFP)”  can  be  used  to  simultaneously 
account  for  true-negative  and  true-positive  characteristics. 

Finally,  Prognostic  algorithms  can  use  a  combination  of 
sensor  data,  a-priori  knowledge  of  a  failure  mode  and 
diagnostic  information  to  predict  the  time  to  a  failure  or 
degraded  condition  with  confidence  bounds.  Prognostic 
algorithms  are  linked  directly  to  failure  modes  in  the 
graphical  FMECA  model. 


The  health  management  design  environment  configuration 
and  attributes  contain  a  sufficient  amount  of  information  to 
generate  and  evaluate  a  “fitness”  function.  This  fitness 
function  is  of  the  form: 

For  each  Failure  Mode  -  FM(i) 

Step  1 )  Probability  of  Failure  *  Severity  *  Consequential 
Cost  of  FM(i)  +  (Downstream  Failure  Mode 
Consequential  Costs)  *  Probability  of  Propagation 
Step  2 )  *FIM  risk  reduction  attributed  to  FM( i ) 

Step  3)  +  Cost  associated  with  False  Alarms  on  FM( i) 

Step  4)  +  Total  Cost  of  all  HM  technology 

The  Consequential  Cost  (CC)  is  the  sum  of  the  direct  and 
indirect  costs  required  to  address  a  particular  fault/failure 
mode  (i.e.  repair,  replace,  inspect)  ranging  from  quantifiable 
repair  and  labor  costs,  to  less  concrete  costs  such  as  the 
effect  on  system  availability.  Clearly,  only  a  small  aspect  of 
all  the  possible  factors  are  addressed  here  and  the  issue  is 
purposely  left  ambiguous.  If  the  probability  of  failure 
multiplied  by  consequential  costs  is  defined  as  risk,  health 
monitoring  reduces  risk  by  providing  a  probability  that  a 
particular  failure  mode  can  be  prevented  by  1)  either 
detecting  an  “upstream”  fault/failure  mode  or  2)  prognosing 
when  a  fault/failure  mode  will  occur.  Unfortunately,  the 
health  monitoring  adds  development  and  hardware  costs  as 
well  as  the  potential  for  false  alarms.  At  the  system- wide 
level,  the  benefits  of  the  health  monitoring  technologies  in 
terms  of  risk  reduction  must  offset  the  costs  and  risk  of  the 
technology  addition. 

Specifically,  the  formulation  is  as  follows  (using  the 
acronyms  defined  in  Figure  7): 

Steps  1  and  2  = 
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Prognostics  do  not  have  an  attribute  associated  with  false 
alarms.  The  “Prognostic  Accuracy”  accounts  for  the  early 
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and  standard  data  formats  such  as  XML,  data  and 
applications  will  be  accessible  individually  through  web- 
based  servers,  and  managed  through  an  integration  layer, 
which  will  control  the  communications  protocol  and  access 
privileges  (Figure  8). 


Step  3  = 
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Finally  Step  4  = 
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HM  Design  Optimization 

The  goal  of  the  HM  system  optimization  is  to  maximize  the 
risk  reduction  provided  by  the  design  while  minimizing 
costs.  The  optimization  of  the  previously  described  cost 
function  will  operate  between  two  boundaries;  a 
“maximum”  HM  system  configuration  that  includes  the 
“wish  list”  of  all  potential  sensors  and  associated  algorithms 
that  achieve  complete  failure  mode  coverage  and  a 
“minimum”  configuration  that  is  necessary  for  safety  and 
control.  The  optimization  algorithm  will  examine  random 
configuration  variations  and  calculate  the  “fitness”  or  cost 
for  each. 

A  genetic  algorithm  optimization  scheme  was  chosen  for  the 
HM  optimization  because  genetic  algorithms  are  better 
configured  to  handle  optimization  problems  with  little 
regard  for  non-linearity,  dimensionality  or  function 
complexity  in  general.  Potential  cost  functions  generated  in 
the  HM  environment  can  include  hundreds  of  independent 
variables  and  thus  makes  it  impractical  to  utilize  traditional 
optimization  techniques  such  as  gradient  decent  or  other 
derivative-based  algorithms.  While  the  details  of  the 
optimization  are  outside  the  scope  of  this  paper,  it  is 
important  to  note  that  there  will  be  no  clear  “winner,”  rather 
many  different  HM  system  configurations  will  be  suggested 
that  the  designer  can  evaluate  on  the  basis  of  additional 
criteria.  More  on  this  subject  can  be  found  in  [7]. 


9.  Collaborative  Design  Environment 

Before  an  example  is  given,  it  is  important  to  address  the 
design  environment  and  associated  architecture  to  enable  the 
entire  process.  A  collaborative  work  environment  is  being 
implemented  in  this  program  to  allow  a  number  of  domain 
experts  to  operate  applications  from  different  locations, 
potentially  on  different  operating  systems,  while  sharing  and 
maintaining  the  same  data.  For  instance,  the  HM  Design 
Tool  will  be  used  to  perform  advanced  component 
simulation  models,  FMEA  and  Cost/Benefit  Models 
simultaneously  at  various  locations.  By  utilizing  the  Internet 
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Figure  8  -  Design  of  Collaborative  Work  environment 


10.  HM  Design  Example 

A  simple,  yet  realistic  example  of  a  Health  Management 
design  evaluation  is  shown  next.  In  this  example,  an 
electrically  actuated  control  valve  concept  is  addressed  for 
an  aerospace  application.  Recall  that  a  HM  design  model 
has  many  hierarchies  ranging  from  the  component  level  to 
the  system  level.  For  brevity,  this  example  will  consider, 
but  not  illustrate,  the  far-reaching  system  effects  of  various 
valve  failure  modes.  The  cost  function  for  this  model 
should  by  no  means  considered  complete.  The  purpose  of 
the  example  is  only  to  introduce  the  HM  design  and 
optimization  process. 

The  top  portion  of  Figure  9  shows  a  Line  Replaceable  Unit 
(LRU)  level  Functional  model  of  a  Load  Control  Valve 
(LCV)  that  is  used  to  regulate  discharge  air  from  an 
Auxiliary  Power  Unit  (APU).  Compressed  air  from  the 
APU  is  used  for  main  engine  starts,  environmental  control 
and  several  other  functions.  The  “in”  and  “out”  bars  on  the 
left  and  right  of  the  model  are  used  to  propagate  signals, 
flows,  and  effects  between  levels. 
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Figure  9  -  Functional  Model  and  HM  design  for  LCV 


The  bottom  portion  of  Figure  9  shows  the  unit  level 
maintenance  task  (denoted  by  the  “U”)  to  remove/replace 
the  LCV.  Also  shown  are  the  candidate  health  monitoring 
algorithms  that  have  the  potential  to  detect  a  valve 
degrading  in  performance  and  allow  for  proactive 
maintenance.  Algorithm  #1  trends  the  relationship  between 
LCV  command,  motor  current,  and  the  actual  actuator 
position.  In  this  scenario,  the  LVDT  used  to  monitor  the 
actuator  position  is  a  candidate  sensor.  Algorithm  #2  trends 
the  APU’s  exhaust  gas  temperature  and  speed  with  respect 
to  the  LCV  command.  All  the  sensors  used  for  Algorithm 
#2  are  available  for  “free”  because  they  are  required  for 
control  purposes. 

Figure  10  shows  the  HM  design  at  the  torque  motor  level. 
Contained  at  this  level  is  a  failure  mode  of  torque  motor,  the 
effects  of  such  a  failure,  and  maintenance  tasks  on  the 
motor.  Also  shown  is  an  existing  Built-In-Test  (BIT)  based 
on  the  torque  motor  current.  This  BIT  is  either  0  or  1  and 
can  provide  no  prognostic  capability  or  truly  isolate  a  failure 
mode. 
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Figure  10  -  HM  design  at  the  Torque  motor  level 

Figure  1 1  illustrates  the  HM  design  at  the  actuator  where  the 
LVDT  would  physically  exist.  Note  that  due  to  the  cause 
and  effect  relationship,  failure  of  the  actuator  position  to 
function  could  be  the  result  of  a  torque  motor  problem  or  an 
actuator  failure  mode.  Finally,  Figure  12  is  the  HM  design 
for  the  butterfly  valve.  Many  upstream  failure  modes  can 
cause  it  to  malfunction  creating  potentially  creating  more 
critical  downstream  failure  modes  such  as  insufficient 
avionics  cooling,  inability  to  start  the  main  engines,  etc. 
Clearly,  such  a  model  should  continue  through  system 
interactions  until  end  effects  are  reached. 
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Figure  1 1  -  HM  design  for  Actuator 
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Figure  12-  HM  design  for  Butterfly  valve 

Figure  13  provides  a  concise  illustration  of  some  of  the 
attributes  assigned  to  the  HM  elements  in  Figures  9-12  that 
were  used  in  evaluating  the  cost  function.  Other 
“expensive”  fault/failure  modes  such  as  inability  to  start  the 
main  engines  and  inadequate  avionics  cooling  were  also 
included.  For  brevity,  the  details  of  the  cost  function 
analysis  will  not  be  given.  In  this  simple  study,  the  LVDT 
sensor  and  algorithm  #1  where  found  not  to  provide  enough 
risk  reduction  for  the  cost,  rather,  algorithm  #2  should  be 
implemented.  There  are,  of  course,  a  number  of  variables 
contributing  to  this  result  the  most  dominent  being  the  fact 
that  algorithm  #2  uses  existing  sensors  even  though  it 
provides  lower  diagnostic  confidence  and  was  assigned 
higher  development  costs. 
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Figure  1 3  -  Costs  and  probabilities  for  the  HM  design 


11.  Conclusion 

An  approach  has  been  presented  that  extends  traditional 
FMECA  and  system  modeling  capabilities  to  aid  in  the 
design  of  complex  health  management  systems.  This 
approach  utilizes  a  graphical  and  collaborative  design 
environment  where  failure  modes,  failure  mode 
symptoms/effects,  sensors,  and  diagnostic/prognostic 
technologies  are  represented.  The  health  management 
system  configuration  can  be  optimized  from  a  cost/benefit 
through  analysis  of  the  fitness  attributes  on  HM  system 
building  blocks.  The  ultimate  objective  of  this  approach 
was  to  form  a  methodology  and  environment  which  enables 
effective  health  management  practices  by  mitigating  or 
preventing  failure  modes  while  still  keeping  sensor  and 
diagnostic/prognostic  technology  costs  at  a  minimum. 
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